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ABSTRACT 



An automaton capable of providing an access control deci- 
sion upon receiving an access control request is produced by 
processing context based access control policies specified in 
a formal descriptive language, and by converting the context 
based access control policies to the automaton. 
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Build Automaton(graph){ 

left Automaton = NULL; 
right Automaton = NULL; 
root = Root Of (graph); 

If (left - child (graph)! = NULL){ 

left Automaton = Build Automaton (left - child (graph)); 

} 

If (right - child (graph)! = NULL){ 

right Automaton = Build Automaton (right - child (graph)); 

} 

Resolve (root, left Automaton, right Automaton); 

} 

Resolve (root, left Automaton, right Automaton ){ 

Switch (root is of the form){ 

Qa (x): Build Q(a, x, automaton); 

x < y: BuildxLTEy (x, y, automaton); 

x € X: BuildxinX (x, X, automaton); 

3x: Projection Operation (x, automaton); 

3X: Projection Operation (X, automaton); 

a: And Operation (automatonl, automaton2); 

v: Or Operation (automatonl, automaton2); 

-.: Not Operation (automaton); 

} 
} 



fig* 3 
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POLICY LANGUAGE AND STATE MACHINE 

MODEL FOR DYNAMIC AUTHORIZATION 

IN PHYSICAL ACCESS CONTROL 

TECHNICAL FIELD 

[0001] The technical field of this application concerns a 
language that is useful in specifying dynamic and/or con- 
text-dependent policies for enforcing physical access con- 
trol, and/or an automata used to formalize these policies in 
a executable form. 

BACKGROUND 

[0002] Existing access control systems for physical access 
control (i.e., systems that grant/deny access to restricted 
areas such as rooms) rely on a centralized architecture to 
make the grant/deny decisions. Specifically, the access 
points such as doors to the restricted areas of a facility are 
equipped with readers which are connected to a centrally 
located controller. A user requests access to a particular 
restricted area by presenting an identification device such as 
an access card to a reader. Upon reading the identification 
device, the reader communicates the information read from 
the identification device to the centralized controller. The 
centralized controller makes the grant/deny decision and 
communicates this decision back to the reader which, in 
turn, implements the decision by suitably controlling an 
entrance permitting device such as a door lock. 
[0003] Access control policies are used by the centralized 
controller to determine whether users are to be granted or 
denied access to the restricted areas. These access control 
policies for all users are typically stored explicitly in an 
Access Control List (ACL), and the controller's decision to 
grant or deny access to a particular user is based on a lookup 
into this list. Currently, Access Control Lists are static 
structures that store all of the policies for all of the users. 
Such policies might provide, for example, that user A can be 
allowed access to room R, that user B cannot be allowed 
access to room S, etc. 

[0004] Centralized access control systems with static 
policy specifications as described above cannot be scaled up 
effectively to meet the requirements for the secure protection 
of large facilities such as airports, stadia, etc. that have a 
large number of users. Such facilities instead require 
dynamic (as opposed to static) access control policies that 
are context/ state dependent. Dynamic access control policies 
that are context/ state dependent specify grant/deny access to 
users based on dynamic events such as the occupancy of a 
room being limited to its capacity, the time of an access 
request being between particular temporal values, etc. 
Examples of context sensitive policies include (i) limiting 
access to a restricted area to not more than 20 users at any 
one time (according to which access is allowed to a request- 
ing user as long as the occupancy of the restricted area is 20 
or less and is otherwise denied), (ii) user A is allowed into 
a restricted area only if supervisor B is present in the 
restricted area, etc. 

[0005] There is a need for a formalistic specification 
language that can be used to specify dynamic policies. These 
policies can then be "analyzed" and stored in a memory or 
other suitable structure as an execution model. This execu- 
tion model may be an automaton and can be used to make 
an allow/deny decision in response to every access request. 
The policy language and the execution model should be 



devised in such a way that they are applicable for de- 
centralized access control frameworks and also are ame- 
nable to centralized execution. 

[0006] As an example, the above requirements can be met 
by (1) a formal logical language that is used to specify 
access control policies whose context varies dynamically, 
and (2) an executable state machine model that is used to 
implement the policies specified using the formal logical 
language. 

SUMMARY OF THE INVENTION 

[0007] According to one aspect of the present invention, a 
method is implemented on a computer for producing an 
automaton capable of providing an access control decision 
upon receiving an access control request. The method com- 
prises the following: accepting context based access control 
policies specified in a formal descriptive language, process- 
ing the context based access control policies specified in the 
formal descriptive language; and, converting the context 
based access control policies to the automaton. 
[0008] According to another aspect of the present inven- 
tion, a method is implemented on a computer for producing 
finite state automata capable of providing an access control 
decision upon receiving an access control request. The 
method comprising the following: reading context based 
access control policies specified in a formal descriptive 
language; converting the context based access control poli- 
cies specified in the formal descriptive language to Monadic 
Second Order formulae; and, converting the Monadic Sec- 
ond Order formulae to the finite state automata. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] These and other features and advantages will 

become more apparent from the detailed description when 

taken in conjunction with the drawings in which: 

[0010] FIG. 1 illustrates an example topology of a facility 

that can be protected by an access control system; 

[0011] FIG. 2 illustrates a parse tree corresponding to a 

portion of a policy described below; 

[0012] FIG. 3 illustrates pseudo code of an example policy 

analyzer algorithm useful in explaining features of the 

present invention; 

[0013] FIG. 4 is a flow chart illustrating the manner in 

which policies are implemented an execution model for an 

access control system; 

[0014] FIG. 5 illustrates a finite state automaton obtained 

as a result of applying an example policy analyzer to an 

example Monadic Second Order formula FIG. 6 shows an 

example of an access control system; 

[0015] FIG. 7 shows a representative one of the smart 

cards of FIG. 6; 

[0016] FIG. 8 shows a representative one of the readers of 

FIG. 6; and, 

[0017] FIG. 9 shows a representative one of the door 

controllers of FIG. 6. 

DETAILED DESCRIPTION 

[0018] A formal event-based specification language is 
described herein that is useful in specifying policies. This 
specification language is expressive for a useful range of 
policies in access control and provides a terse description of 
complex policies. The language is amenable to execution 
through equivalent finite state automata that act as machine 
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models of the policies specified using the specification 
language. This specification language can be exploited to 
derive frameworks for access control that provide support 
for dynamic policies. 

[0019] The language and/or the automata implementing 
the policies specified by the language are applicable in any 
physical access control architecture where the need arises to 
enforce access decisions based on dynamically changing 
parameters. The access control policies can be converted 
into their equivalent execution models (automata) and can 
be enforced by placing these models in appropriate access 
control devices such as access cards and/or readers/door 
controllers. 

[0020] Thus, a logical language is disclosed herein and 
can be used to specify dynamic policies. Also, a state 
machine model is disclosed that accepts precisely those 
behaviors that adhere to the dynamic policies. The behavior 
of the access control system is described by sequences of 
events. Events are atomic entities that represent basic com- 
putations. Examples of events include a request by a par- 
ticular user for access to a room R, an occurrence of fire in 
one or more rooms, the occupancy of a room reaching its 
capacity, etc. 

[0021] Additional policy examples include (i) user Abeing 
allowed entry into room R only if a supervisor entered it q 
seconds earlier and is present in room R, (ii) the door of 
lobby L being opened for entry only if the doors of all inner 
rooms are open. 

[0022] Formulas of the logical language are used to write 
policies that describe properties of the sequence of events 
representing the behaviors and that partition the set of 
behaviors into those that are those valid and those that are 
invalid with respect to the policies. A Monadic Second Order 
Logic, for example, which is parameterized by the set of 
events, can be used as the logical language to specify the 
desired policies. 

[0023] The logic has variables that are instantiated by 
events. The logical language also has atomic formulas that 
relate to the occurrence of a particular event and the order of 
occurrence of two events. 

[0024] The formulas of the logic describe policies and are 
built upon the atomic formulas by the use of operators, 
including conjunction and negation, and by quantifying the 
variables. 

[0025] Finite state automata are used as state machine 
models for executing the policies. As is well known, a finite 
state machine possesses a finite set of states and transitions. 
The transitions dictate how a change is made from one state 
to another in response to a particular event. 
[0026] Automata that are constructed based on the policies 
specified by the language described herein are then arranged 
to act as execution models for these policies in the following 
manner: given a specified policy or a set of specified 
policies, a "policy analyzer" algorithm constructs a finite 
state automaton that accepts precisely those behaviors that 
satisfy the specified policy or set of specified policies. This 
algorithm is defined by inducting on the structure of the 
formula representing the policy. The inductive proof exploits 
the fact that the set of behaviors accepted by the finite state 
automata are closed under operations of union, intersection, 
complementation, and projection. 

[0027] A physical access control system deals with grant- 
ing or denying access by users to restricted areas (e.g., 
rooms/locations). A physical access control system com- 



prises subjects, objects, and policies. Subjects are entities 
that represent users who are trying to gain access to certain 
restricted locations, typically rooms. Subjects are subse- 
quently referred to herein as users. Objects (or resources) 
represent, for example, restricted areas such as rooms into 
which users are requesting access. Objects are subsequently 
referred to herein variously as restricted areas or rooms. 
Policies are rules that dictate whether a user is granted or 
denied access to enter a certain restricted area. 
[0028] In typical centralized access control systems, doors 
of rooms are equipped with readers that are connected to a 
central controller. Users request access to rooms by present- 
ing their access cards to the readers. Upon reading the cards, 
the readers communicate information read from the card to 
the central controller. The central controller makes the 
grant/deny decision per certain access control policies, com- 
municates the decision to the readers, and these decisions of 
the central controller are, in turn, enforced by the readers. 
[0029] As discussed above, policies for all users in a 
centralized system are stored explicitly in an Access Control 
List, and the decision of the central controller is based on a 
lookup into this list. Access Control Lists are static struc- 
tures that are configured to store policies for every user. 
Typical policies are user si is allowed access to room R, user 
s2 is not allowed access to room S, etc. 
[0030] In existing infrastructures, readers have to commu- 
nicate with the central controller in order to obtain a decision 
for every access request. This reliance on a central controller 
inhibits expansion of the access control system to meet the 
needs of future intelligent facilities that support a very large 
number of users and that communicate over a distributed 
network of wired and wireless components. 
[0031] Consequently, such systems do not scale up 
adequately to meet the requirements for securing such large 
and sensitive facilities as airports, stadia, etc. These facilities 
require dynamic access control policies that are context/ state 
dependent, i.e., policies that grant/deny access to users based 
on dynamic events such as whether or not the occupancy of 
a room is equal to its capacity, whether or not there is an 
occurrence of a fire, etc. 

[0032] Static policies represented by Access Control Lists 
are not expressive enough to represent dynamic rules. An 
attempt could be made to exhaustively list all of the various 
scenarios that describe the context that will foreseeably 
result in access being granted or denied in response to a 
request, but this exhaustive listing would result in an Access 
Control List of potentially infinite size. 
[0033] Other approaches, such as present day solutions 
that combine intrusion detection and access control, depend 
on "special" if-then-else rule specifications of limited 
expressibility that necessitate the central controller to query 
the intrusion detection module prior to giving access. Such 
solutions work on a case by case basis and do not have a 
framework for generic specification of context-dependent 
policies. 

[0034] What is needed is a language to define complex 
policies with features to handle various dynamic parameters 
such as time, context induced by the state of other rooms in 
the facility, etc. These policies can then by analyzed and 
stored in an executable form where a reply for each access 
request is made based on the values of the various influ- 
encing parameters. 

[0035] In order to accommodate such future intelligent 
large facilities, it would be efficient for the access cards 
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and/or the reader/controllers that are installed at the doors to 
make the access/deny decisions without requiring commu- 
nication with a central authority. Such a de-centralized 
approach can be realized according to one embodiment by 
making the executable model of the policies amenable to 
de-centralization, i.e., the model should be generic enough 
to be implemented over a wide range of access control 
devices ranging from smart cards to micro controllers. 
[0036] One approach is to use a formal logical language to 
specify dynamic access control policies, an executable finite 
state machine model that implements the policies specified 
in the formal language, and a policy analyzer that generates 
state machines by recognizing those behaviors of the system 
that adhere to the policies. 

[0037] One formal logical language that can be used for 
these purposes is a Monadic Second Order (MSO) Logic 
that is parameterized by the events of the system as the 
formal language for specifying policies. A language that is 
useful herein is disclosed by Thomas, W. in "Languages, 
automata and logic," in Handbook of Formal Languages, 
Vol. Ill, Springer, N.Y, 1997, pp. 389-455. 
[0038] Events of the system depict actions of a user 
requesting entry into a room, a user being present in a room, 
occupancy of a particular room reaching its pre-defined 
capacity, etc. 

[0039] The logic is built over a countable set of first order 
and second order variables that are instantiated by events 
and sets of events, respectively, and a set of atomic formulas 
that are relation symbols which identify occurrence of 
events, dictate ordering between events, and indicate mem- 
bership of an event in a set. Thus, first order variables are 
used to quantify over a single event, and second order 
variables are used to quantify over a finite set of events. 
[0040] The basic building blocks of the policy language 
that will be used in defining the alphabet of the system are 
now described. The alphabet constitutes the set of labels for 
the events of the system. Each label identifies a correspond- 
ing event such as requesting access, granting access, deny- 
ing access, a supervisor entering a room, etc. 
[0041] According to the syntax of the language, S denotes 
the set of users (subjects). The set S may, as desired, be 
partitioned into two subsets TS and PS, denoting temporary 
users and permanent users, respectively. Permanent users 
may, as desired, be further classified into normal users, 
supervisors, directors, etc., by using separate characteristic 
functions depending on need. For convenience and not 
necessity, it may be assumed that there exists a finite set 
User_types={normal, supervisor, director, . . . } of all 
possible types of users, and a function user_type: S— »User_ 
types that assigns a user to a user type. 
[0042] Another way of classifying permanent users may 
be based on a hierarchy that defines the rank/status of each 
such user. The rank of a user may be used to make a 
grant/deny access decision regarding a particular room. For 
example, only those users of a certain type may be allowed 
access to rooms of a certain type. A hierarchy among users 
may be defined using a partial ordering of the set PS. If = 
is a partial order on PS, and if x and y are users such that 
x=y, then y is of a higher rank than x, and policies may 
dictate that y has access to more rooms than x. Accordingly, 
user types may be modeled as described above. 
[0043] Also, according to the syntax, the nomenclature O 
is used herein to denote a set of objects (e.g., restricted areas 
(such as rooms), doors, etc.). The following functions are 



associated with the set O, keeping in mind the typical 
policies that are used in physical access control. 
[0044] The nomenclature Room_types is used herein to 
denote a finite set of room types. Types are used to classify 
the rooms inside a building. The function room_type: 
O— »Room_types associates each room with a room type. A 
room need not necessarily be thought of in a conventional 
sense and may be thought of more broadly as a restricted 
area to which access is controlled. 

[0045] To capture policies that exploit the possibility that 
each room can have many doors, the set of doors associated 
with each room may be considered as another basic entity. 
The nomenclature D is used herein to denote the set of doors 
of the facility. The one-to-one function doors: O— »(2' D \(|)) 
associates a non-empty set of doors with each room. A door 
need not necessarily be thought of in a conventional sense 
and may be thought of more broadly as a portal or other 
access point through which access to a resource is con- 
trolled. 

[0046] Policies may be written as formulas of Monadic 
Second Order Logic. Formulas are built from atomic for- 
mulas which, in turn, are built from terms. Since the logic is 
parameterized by the set of events/actions of the system, it 
is beneficial to first define the alphabet of actions. 
[0047] The set of actions 2 includes the following: for seS, 
oeO, and d edoors(o), the actions req_entry(s, user_type(s), 
o, room_type(o), d ), allow_entry(s, user_type(s), o, room_ 
type(o), d ) and deny_entry(s, user_type(s), o, room_type 
(o), d ) are used to represent events corresponding to a user 
s (of type user_type(s)) requesting entry into restricted area 
o (of type room_type(o)) through access point d , to a 
decision allowing a user s (of type user_type(s)) to enter into 
restricted area o (of type room_type(o)) through access point 
d , and to a decision denying a user s (of type user_type(s)) 
entrance into restricted area o (of type room_type(o)) 
through access point d , respectively. 
[0048] Similarly, for seS, oeO, and d edoors(o), the 
actions req_exit(s, user_type(s), o, room_type(o), d ), 
allow_exit(s, user_type(s), o, room_type(o), d ) and deny_ 
exit(s, user_type(s), o, room_type(o), d ) are used to repre- 
sent events corresponding to a user s requesting exit from 
restricted area o through one of its access points d , to a 
decision allowing a user s (of type user_type(s)) to exit from 
restricted area o (of type room_type(o)) through access point 
d , and to a decision denying a user s (of type user_type(s)) 
the right to exit restricted area o (of type room_type(o)) 
through access point d , respectively. 
[0049] For seS and oeO, the action "s in o" denotes the fact 
that the user s is inside the restricted area o. 
[0050] Other actions may also be similarly formulated. 
For example, in addition to the above listed actions, there are 
events which pertain to specific policies. For example, if a 
policy requires that, at all times, not more than 20 users can 
be present in a particular room, then the occupancy of the 
room reaching 20 is modeled through an event which is used 
in the policy specification. All the events in this category 
will be those that control access of users to specific rooms. 
Such events include, for example, an event requiring a 
supervisor to be present in a room, an event depicting the 
fact that time is between two values, etc. and will be referred 
to as context events. 

[0051] Atomic formulas, such as those mentioned above, 
are defined as follows: (i) a set of actions 2 is fixed, and for 
each action ae2, there is a predicate Q a (x) which represents 
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the fact that the label of an event represented by a first order 
variable x is a; (ii) for first order variables x, y, the predicate 
x=y represents the condition that the event corresponding to 
x occurs before the event corresponding to y in a compu- 
tation of the system; and, (iii) for a first order variable x and 
a second order variable X, the atomic formula xeX repre- 
sents the fact that the event corresponding to the variable x 
belongs to the set of events corresponding to X. 
[0052] In the above, certain assumptions regarding users 
entering and exiting rooms are optionally made. Thus, if a 
request from a user to enter a room is granted, it is assumed 
that the user enters the room. Similarly, if a request from a 
user to exit a room is granted, it is assumed that the user exits 
the room. In addition, the user should already be in a room 
to make a request to exit from it. 

[0053] Formulas depicting policies are built from the 
above atomic formulas using the following connectives: (i) 
Boolean operators -i,v,A,=>,and = represent negation, dis- 
junction, conjunction, implication, and equivalence, respec- 
tively, and the operators A(conjunction), =>(implication), 
and = (equivalence) can be derived from -,and v; and, (ii) 
the operators V (for all) and 3 (there exists) are used to 
quantify over first and second order variables. 
[0054] To summarize, the syntax of the policy language is 
basically Monadic Second Order Logic tuned to the context 
of access control. As mentioned earlier, the logic is param- 
eterized by events represented as members of the action set 
2. 

[0055] The semantics of policies may be defined using 
words over the alphabet 2. Words are finite sequences of 
actions from the action set 2. A formula <|) is interpreted over 
a word w as follows: an interpretation of first and second 
order variables is a function I that assigns a letter of 2 to 
each first order variable and a set of letters of 2 to each 
second order variable. These letters occur as positions in a 
word when a formula (policy) is evaluated over it. For a 
formula <|), V^ may be used to denote the variables that are 
free variables in the formula <|), i.e., the variables V^ are not 
in the scope of any quantifier in <|). Interpretation is then 
nothing but a function I: V^— »2. For a first order variable x, 
I(x) represents an event from 2 as assigned by the interpre- 
tation function I. Similarly, for a second order variable X, 
I(X) represents a set of events from 2 as assigned by the 
interpretation function I. In the context of access control, 
I(x) could represent the event of a user requesting access to 
a particular room, and I(X) could represent a set of context 
events. 

[0056] The notion of when a word w satisfies a formula <|) 
under an interpretation I is denoted by w^ and is defined 
inductively as follows: 
[0057] w h/2 a (x) if and only if I(x)=a. 

[0058] w|= 7 x=y if and only if I(x) occurs before I(y) in the 
word w. 

[0059] w |= 7 xeX if and only if I(x)eI(X). 

[0060] w^^ if and only if it is not the case that w^. 

[0061] w^jVi^ if and only if w^j or w^j. 

[0062] w|= 7 3x<|) if and only if there exists an interpretation 

function I' that extends I by assigning an event to the 

variable x such that w^. 

[0063] w|= 7 3X<|) if and only if there exists an interpretation 

function I' that extends I by assigning a set of events to the 

variable X such that w|= 7 x|). 



[0064] The semantics of every formula <|) is defined induc- 
tively on the structure of the formula as above. A word w 
satisfies the atomic formula Q a (x) under an interpretation I 
if and only if the event assigned to the first order variable x 
by I is a. A word w satisfies the atomic formula x=y under 
an interpretation I if and only if the position of the event 
assigned to x occurs before the position of the event assigned 
to y by I. A word satisfies the atomic formula xeX under an 
interpretation I if and only if the event assigned to the first 
order variable x by I belongs to the set of events assigned to 
the second order variable X by I. 

[0065] Similarly, a word w satisfies the formula -, <|) under 
an interpretation I if and only if it is not the case that w 
satisfies the formula <|). A word w satisfies the formula (^vf^ 
under an interpretation I if and only if it satisfies at least one 
of the formulas i^ 1 or <|) 2 under I. Finally, a word w satisfies 
the formula 3x<|)(3X<|)) under an interpretation I if and only 
if there is another interpretation function I' that extends I by 
assigning an event (or a set of events) to x (or X) such that 
w satisfies the formula <|) under the new interpretation 
function I'. 

[0066] In the context of access control, an interpretation 
function I could, for example, assign a first order variable to 
a "request for access" event. 

[0067] A sentence is a formula without any free variables, 
i.e., all the variables occurring in the formula are bound by 
a quantifier. Sentences can be assigned semantics without 
any interpretation function. As desired, the policy language 
used in a physical access control system may be such that all 
policies will be sentences in Monadic Second Order Logic. 
[0068] In discussing the details regarding using Monadic 
Second Order Logic as the language for configuring access 
control policies of a facility, it may be optionally assumed 
that information regarding the topology (rooms, their neigh- 
bors, doors, etc.) of the facility and information regarding 
the users using the facility are available to an administrator 
configuring the policies. To justify the fact that Monadic 
Second Order Logic is an event-based language, it may first 
be noted that events are entities that represent access control 
requests, decisions, and context. All the events describing 
context are "programmable" in each controller/relevant 
access control device. Thus, context related events can be 
realized as physical events along with the events of users 
requesting access and being granted/denied access. 
[0069] An interface may be provided such that a template- 
based English specification of policies can be configured by 
an administrator using Monadic Second Order Logic to 
specify policies. A high-level policy analyzer entity then 
converts these English templates into their equivalent 
Monadic Second Order Logic formulas, making it user- 
friendly. The template based configuration of policies is 
done such that it supports role based access control, where 
the roles of users are defined based on the policies that are 
being enforced on them. The template based configuration 
and Monadic Second Order logic are also expressive enough 
to encode static policies as specified using Access Control 
Lists. For example, user A can always enter room R. Note 
that the context becomes empty in such a case. 
[0070] Care should also be taken to ensure that the 
Monadic Second Order Logic formulas constitute a compact 
representation of access control policies. For example, using 
the fact that, in physical access control, a reply to an access 
request can only be either allow or deny, certain assumptions 
can be made to the effect that, in the absence of any explicit 
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policy, the reply to a request will be a denial by default (or 
an allowance by default). This assumption can then be 
programmed into the controllers, and an exhaustive listing 
of when to allow or deny upon request to each room can be 
avoided. 

[0071] The following demonstrates the usage of the lan- 
guage as described above for specifying policies, using the 
facility of FIG. 1 as an example. From FIG. 1, it is clear that 
the set O of rooms is {W, A, B, C, M, N, P, Q, T}, and that 
the set D of doors of the facility is given by D={D 100 w , 

*-*WA> LJwB> LJCB> LJaO *-*AM*-*AN> *-*MN> *-* AB> ^BT> ^BP' 

Dpg}- This information is made available as a part of the 
high-level policy analyzer module. The various events that 
constitute the alphabet 2 will be detailed as and when the 
policies in which they are used are described. 
[0072] Some dynamic policies involving various param- 
eters like time, context imposed by the state of other rooms, 
etc., are presented below along with the formulas specifying 
them. 

[0073] For the sake of readability, for ae2 and a variable 
x, the notation a(x) is used to denote the predicate Q a (x). 
Also, in the formulas below, the relation < denotes the 
immediate successor of the relation = and is defined as 
follows: for variables x, y, x<y if and only if (x=y)A-i3z 
((x = z)a(z=y)). In words, x occurs immediately before y if 
and only if x occurs before y and there does not exist any z 
that occurs after x but before y. 

[0074] The policies described below are defined on a per 
user basis, i.e., they describe rules for access of a single user 
at a time. In the action symbols described below, whenever 
the user/room type is not explicitly mentioned by the policy, 
we use the symbol _ to represent the fact that it is applicable 
to each user/room (with the user/room type instantiated 
accordingly). 

[0075] As the examples indicate, the policies have the 
structure of an initiating access request action followed by a 
description of the context and a decision based on its truth 
or falsity. 

[0076] Anti-pass back: An example of this policy reads in 
English as follows: A user s cannot enter from <|) to W if the 
user s has a record of entering W through D^but not exiting 
W. The Monadic Second Order Logic specification of this 
policy is given by the following formula: 

Vx([req-entry(.s,_, W,_,D^)(x)A3y((s in Wiy) 

(ySx))A 3z-i allow-exit(.s,_, J^_,D. w )(z)A((ySz) 
A 
A(zSx)))] => 3 x'((xSx')Adeny-entiy(s,_, W,_,D^) 

(*')))■ 

[0077] The above policy reads as follows: For every event 
of the form req-entry(s, _, W, _, D^) represented by the first 
order variable x (using the atomic formula req-entry (s, _, W, 
_, D (|)W ,)(x)), and the context defined by the presence of the 
first order variable y occurring before x representing the fact 
that the user s was present in the room W (using the atomic 
formula s in W (y)) and the absence of the first order variable 
z occurring between y and x, representing the fact that the 
user s was not allowed exit from W (using the formula 
-, allow-exit(s, _, W, _, D^) (z)) through the door T)^ w , the 
access decision taken is a deny represented by the first order 
variable x' occurring after x (using the atomic formula 
deny-entry (s, _, _, D^) (x')). 

[0078] A policy regarding interlocking of doors might read 
in English as follows: D BP can open if Dp e is closed. 



[0079] In the following, it is assumed that a door is open 
if and only if it allows entry and exit to all requesting 
subjects. A door D being closed is modeled by (the genera- 
tion of) an event closed(D). The event not-closed(D) repre- 
sents the "negation" or "dual" of the event closed(D) (a 
member of 2). The two formulas below capture the scenarios 
corresponding to entry and exit, respectively. 

Vx([req-entry(.s, ,P, ,D bp )(x)a3 y(closed(D P Q)(y) 

(ySx))A-i3znot-closed(D PO )(z)A((ySz)A(zSx))] 
A ^ 

3x'((x^ix')Aallow-entry(5, ,P, ,D BP ) (x')) . 

Vx([req-exit(.s, ,P, ,D bp )(x)a3 y(closed(D P Q)(y) 

(ySx))A-i3znot-closed(Z)p )(z)A((ySz)A(zSx))] 
A ^ 

3x'((x^ix')Aallow-exit(5, ,P, ,D BP ) (x')). 

[0080] Similarly, for the policy which states that Dp e can 
open if D BP is closed, two Monadic Second Order Logic 
formulas can be written describing the scenario relating to 
entry and exit of subjects. 

[0081] A policy regarding assisted access might read in 
English as follows: a normal user cannot enter/exit Q 
without an administrator having entered/exited it q seconds 
before. The following assumptions are made before defining 
the formula corresponding to this policy: an administrator 
entering the room Q is modeled by an event adm-ent(Q), and 
the fact that more than q seconds have elapsed since his/her 
entry is modeled by another event adm-ent c? (Q). The fol- 
lowing Monadic Second Order Logic formula then captures 
the assisted access policy. 

Vx([req-entry(.s .normal, g, ,Dpq)(x) 

3^(adm-ent(g)(j')A()'Sx))A-i3z(adm-ent„(g)(z) 
A 

((y=z)A(z^=x))]^ 3x'((x^ix')Aallow-entry(5,nor- 
mal,e,_,.D Pe )(x'))). 

[0082] Again, to capture the corresponding policy related 
to exit, it is assumed that there are events adm-exit(Q) and 
adm-exit (Q) that capture administrator exiting Q and exit- 
ing Q q seconds before, respectively. The Monadic Second 
Order Logic specification of the policy then reads as 

Vx([req-exit(.s .normal, g, ,Dpq)(x) 

3;<acta-exit(g)(j)A(j§x))A-i3z(adm-exit„(g)(z) 
A 

((y=z)^(z^=x))]A 3 x'((;v^i;v')Aallow-exit(.s .normal, 
&^D Pe )(x'))). 

[0083] A counter policy is that no normal user can enter C 
from either D AC or D BC if the number of subjects in C is 
more than its capacity. The fact that the number of users in 
the room C exceeds its capacity is modeled by an event 
C max . The following formula then states the above policy. 

Vx(C„, ax (x)=>Vy((x§y) 

req-entry(.s .normal, C, ,D AC )A{ -i 3z((x^iz)A(z^)) 

A 
not-C max (z)) => 3 x'((y<v')Adeny-entry(.s .normal, 

&_,D AC )(x')))))- 

req-entry(s,normal,C, ,D BC )A{ -i ^z{{xfkz)A{zfky)) 

A 
not-C max (z)) => 3 ;v'((j<x')Adeny-entry(s,normal, 

&„A,c)M)))). 

[0084] In a temporal policy, normal users can enter room 
T only between times T 1 and T 2 everyday. The fact that 
current time is between T 1 and T 2 is modeled by an event 
time (T 1; T 2 ). 
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[0085] The following formula then captures the policy: 

Vx([req-entry(.s .normal, Z^ ,D BT )(x) 

3^(time(r 1 ,r 2 )0)AOSi))A-i3z(not-time(r 1 ,r 2 ). 

(z)A((jSz)A(zSx))]=>3x'((xSx')Aallow-entry(i, 
normal,^ ,D BT )(x'))). 

[0086] Certain policies for special categories of rooms 
might dictate that a particular user present his/her card twice 
to gain entry into the room. The following policy allows 
entry only on at least two consecutive requests by an user: 

VX( [xeXAyeXAieq-entry(s,^P,_,D BP ) (x) 

req-entry(.s, ,P, ,D BP )(y)A(x<y)\ => 3 x'((y^=x') 

allow-entry(5, ,P, ,D BP )(x')). 

A 

X is a second order variable in the above policy formula that 
has two first order variables x and y as its members repre- 
senting two consecutive requests by a user s into the room 
P through the door D BP . 

[0087] A machine model may be used to model these 
policy formulas. As mentioned earlier, Monadic Second 
Order Logic acts as a descriptive language to specify poli- 
cies that are context-dependent. In order for the policies 
specified in Monadic Second Order Logic to be operational 
in terms of enforcing access, they have to be converted into 
computational/executable models. These models can then be 
stored in appropriate locations for execution. 
[0088] Conventional finite state automata may be used as 
the machine models that execute policies. 
[0089] Definition: A finite state automaton over an alpha- 
bet 2 is a tuple A=(Q, X, — », I, F) where 
[0090] Q is a finite set of states, 

[0091] I, F<=Q is the set of initial and final states, respec- 
tively, and, 

[0092] — »_<^(Qx2xQ) is the transition relations between 
states. 

[0093] As discussed above, 2 is a finite set of actions. An 
automaton need not have a transition for every action in 2. 
While using these automata as execution models for enforc- 
ing access control policies, 2 will become the set of actions 
as used in the policy examples. 

[0094] The semantics of finite state automata is presented 
here in terms of its runs on a given input. The input is a word 
over 2. Given a word w=a 1; a 2 , . . . , an as an input (i.e., the 
word w is made up of actions a 1; a 2 , . . . , a„), a run of the 
finite state automaton A on the word w is a sequence of states 
q , q 1; . . . , q„ such that q el and (q,, a„ q, +1 )e-»for i varying 
from to n. In other words, the action a t causes the finite 
state automaton to transition from the initial state q to the 
state q 1; the action a 2 causes the finite state automaton to 
transition from the state q 1 to the state c^, and so on until the 
last action a„ causes transition to the state q„. A run is said 
to be accepting if q„eF (i.e., state q„ is a final state of the 
finite state machine). The language accepted by A is denoted 
by L(A) and is defined as the set of all those words on which 
A has an accepting run. Languages accepted by finite state 
automata are popularly called regular languages. 
[0095] Thus, finite state automata can be viewed as 
machine models executing policies specified in Monadic 
Second Order Logic. A policy analyzer constitutes the set of 
algorithms to convert policies specified in Monadic Second 
Order Logic into their equivalent finite state automata. A 
policy analyzer algorithm follows well-known theoretical 
techniques for converting formula into automata. The fol- 



lowing theorem from Thomas, W. in "Languages, automata 
and logic," in Handbook of Formal Languages, Vol. Ill, 
Springer, N.Y., 1997, pp. 389-455 can be implemented as an 
algorithm for the policy analyzer. 

[0096] Theorem: For every sentence <|), a finite state 
automaton A^ can be constructed such that L(A ( | ) )={ wlwl=<|) } . 
[0097] The above theorem is proven by induction on the 
structure of <|) (as obtained from the syntax of the Monadic 
Second Order Logic). The policy analyzer algorithm may be 
arranged to follow the same inductive structure of the proof. 
The inductive proof uses results involving closure properties 
of the class of regular languages which are standard results 
and can be obtained from any book on the Theory of 
Computation such as, for example, Kozen, D., "Automata 
and Computability," Springer-Verlag, 1997. 
[0098] The policy analyzer algorithm works by induc- 
tively constructing an automaton based on the structure of 
the given MSO formula. The structure of an MSO formula 
<|) is represented using a parse tree T^ that captures infor- 
mation about all the atomic formulas and sub-formulas that 
constitute <|) and also information about how <|) is syntacti- 
cally built using the various Boolean operators and quanti- 
fiers. For example, consider the policy described by the 
MSO formula below that allows entry of a user into a room 
A if and only if the context defined by the event Z holds. 

\fx, 3y :Z(;v)Arequest-entry-^(y) -i3z.— iZ(z)A(x<z) 

(z<y) => 3 iv_:allow-entry-^4(iv)Ay<iv AViv_:al- 

A 

low-entry-^(iv) => 3x,y :Z(;v)Arequest-entry-^(y) 

-\3z:Z(z)A(x<y)A(y<z)_A(y <w) 

The parse tree corresponding to the first outer-most sub- 
formula (the first three lines of the formula) of the above 
policy is given in FIG. 2. 

[0099] Pseudo code of the policy analyzer algorithm is 
given in FIG. 3, and the algorithm works by traversing the 
parse tree using a post-order traversal, inductively construct- 
ing an automaton for each node. The leaf nodes of the parse 
tree are atomic formulas, and automata accepting words that 
satisfy these formula can be constructed using techniques 
available from Thomas, W. in "Languages, automata and 
logic," in Handbook of Formal Languages, Vol. Ill, 
Springer, N.Y., 1997, pp. 389-455. These techniques corre- 
spond to the routines BuildQ, BuildxLTEy, BuildxinX in the 
pseudo code. The routines take the actions or representatives 
of the variables from atomic formulas as arguments, and 
construct and return the corresponding automaton. 
[0100] The inner nodes of the parse tree are either Boolean 
connectives or quantifiers. To construct automata for each 
inner node, the closure operation corresponding to the 
connective or quantifier is used on the automata correspond- 
ing to its children. As mentioned above, the class of regular 
languages accepted by finite state automata is effectively 
closed under these operations. There are algorithms avail- 
able, for example, in Kozen, D., "Automata and Comput- 
ability," Springer-Verlag, 1 997, that can be used to construct 
automata effectively implementing the closure properties. 
These algorithms correspond to the routines ProjectionOp- 
eration, AndOperation, OrOperation, and NotOperation that 
are used in the pseudo code. These routines again take the 
corresponding automata and variable information as needed 
and return the automaton corresponding to the closure 
operation. 
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[0101] FIG. 4 summarizes the full high-level policy ana- 
lyzer algorithm for configuring the policies followed by the 
policy analyzer algorithm that generates the state machines 
for executing the policies. 

[0102] The topology 10 of the facility to be protected, the 
events 11, that are members of 2 and include seS, oeO, and 
d edoors(o), and the template based descriptions 12 that are 
prepared by an administrator and that represent the rules 
and/or policies to be enforced by the system are input to a 
high level analyzer 13. These templates are written in 
English and are defined along with their corresponding 
Monadic Second Order formulas. The high level analyzer 13 
converts the template based descriptions to Monadic Second 
Order formulas 14 having a structure similar to those 
described above. For example, the template corresponding 
to the policy described in the Monadic Second Order Logic 
formula above is given as: 

Can Enter Room A on context Z 

The high level analyzer 13 works by first parsing the above 
templates to extract pieces of templates that can be substi- 
tuted by pre-designated Monadic Second Order formulas. 
The Monadic Second Order formulas of the pieces of 
templates are then put together by the high level analyzer 13 
to obtain the overall Monadic Second Order formula 14 
corresponding to the policy. The high level policy analyzer 
13 uses knowledge of the application domain to effectively 
perform the translation. This translation can be carried out 
using well known parsing techniques available from Alfred 
V. Aho, Ravi Sethi, Jeffrey D. Ullman in "Compilers Prin- 
ciples, Techniques, Tools", Reading, Ma., Addison- Wesley, 
1986, and well known tools disclosed by S. C. Johnson in 
"YACC — Yet another compiler compiler", Technical 
Report, Murray Hill, 1975, and by Charles Donelly and 
Richard Stallman in "Bison: The YACC-Compatible Parser 
Generator (Reference Manual)", Free Software Foundation, 
Version 1.25 edition, November 1995. Thus, the formulation 
of application specific templates and the grammar and the 
consequent construction of the high level policy analyzer 13 
can be carried out in accordance with the existing literature 
as cited above. 

[0103] The Monadic Second Order formulas 14 are now 
converted by a policy analyzer 15 as described by the pseudo 
code in FIG. 3 to a finite state automaton 16. FIG. 5 
illustrates the finite state automaton obtained as a result of 
applying the policy analyzer 15 to the Monadic Second 
Order formula mentioned above. Note that the event Z D in 
the automaton represents the negation or dual of the event Z, 
i.e., the fact that the event Z has not occurred. 
[0104] The policy analyzer 15 can be used to answer some 
of the natural questions that arise in the context of access 
control enforced through policies. One question is whether 
a set of policies can be enforced on a facility. It may be 
assumed that a given set of policies can be enforced on a 
facility if there exists at least one behavior of the system that 
satisfies all these policies. 

[0105] Given a set of policies, using the policy analyzer 
algorithm, an automaton is first constructed that accepts 
precisely those behaviors that satisfy all the policies. It is 
easy to see that this set of policies can be enforced on the 
facility if and only if the associated automaton accepts a 
non-empty language. 

[0106] The problem of checking non-emptiness of a regu- 
lar language is decidable: the policy analyzer 15 operates by 



checking if there is a path in the transition graph of the 
automaton from one of the initial states to one of the final 
states. This problem is decidable and can be implemented 
using a standard depth first search on the graph of the 
automaton. 

[0107] Another question that can be answered as an appli- 
cation of the policy analyzer 15 is that of formally verifying 
policies. Given a set L of behaviors of a system as a regular 
language and a set of policies as formulas in the policy 
language, the problem of model checking is to check if every 
behavior in L satisfies the policies. This question also turns 
out to be decidable. 

[0108] Accordingly, since the given set L is a regular 
language, it is known that there exists a finite state automa- 
ton A L that accepts the set L. The formula <|) obtained by 
taking the conjunction of the formulas corresponding to the 
various given policies is then considered. It is easy to see 
that each behavior in L satisfies <|) (i.e., satisfies all the 
policies) if and only if LnL(-,<|))=<|), where L(-,<|)) denotes 
the set of all words that satisfy <|). We know from the policy 
analyzer 15 that we can construct a finite state automaton A 
^^ such that it accepts precisely those behaviors that satisfy 
-, <j). It is easy to argue that the class of languages accepted 
by finite state automata is effectively closed under the 
set -theoretic operation of intersection. Consequently, solv- 
ing the model checking problem amounts to checking if the 
finite state automaton accepting LQL(-, <|)) accepts an empty 
language, which is again decidable as mentioned above. 
[0109] The logical event-based language for specifying 
policies as described herein is expressive enough to specify 
complex policies involving time, state of other rooms etc. as 
the examples illustrate. A policy analyzer converts these 
policies specified in the language into their equivalent finite 
state automata in the form of machine models. The finite 
state automata may be stored on smart cards and/or in door 
controllers/reader of an access control system. 
[0110] An embodiment of an access control system 40 for 
the control of access to a building with interconnects is 
shown in FIG. 6. The access control system 40 implements 
de-centralized access control (DAC), which is not to be 
confused with Discretionary Access Control. The de-cen- 
tralized access control, for example, may be arranged to fall 
within the domain of non-discretionary access control. 
[0111] The access control system 40 include user-carried 
devices 42 (e.g., smart access cards), readers 44 (e.g., device 
readers), access points 46 (e.g., portals such as doors), 
resources 48 (e.g., protected areas such as rooms), and an 
interconnect 50. 

[0112] The user-carried devices 42 according to one 
embodiment may have built-in computational capabilities 
and memories, as opposed to passive cards that are com- 
monly used today. Users are required to carry the user- 
carried devices 42. The user-carried devices 42 are more 
simply referred to herein as smart cards. However, it should 
be understood that user-carried devices can include devices 
other than smart cards. 

[0113] The readers 44 at the doors or other portals are able 
to read from and write to the user-carried devices 42. 
[0114] The access points 46 are access control enabled. 
The access points 46 are more simply referred to herein as 
doors. However, it should be understood that access agents 
can include vias other than doors. Each of the doors 46, for 
example, may be arranged to have one or more readers 44. 
For example, each of the doors 46 may be arranged to have 
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two readers 44 with one of the readers 44 on each side of the 
corresponding door 46. Also, each of the doors 46, for 
example, may be arranged to have a door controller 52. The 
door controller 52 is connected to the reader 44 and has an 
actuator for locking and unlocking the corresponding door 
46. The door controller 52 may have a wireless/locally wired 
communication component and some processing capabili- 
ties. 

[0115] The resources 48, for example, may be enclosed 
spaces or other restricted areas. Access to the resources 48 
is permitted by the doors 46 with each of the doors 46 being 
provided with a corresponding one of the door-controllers 
52 to control access through a corresponding one of the 
doors 46 and into a corresponding one of the resources 48. 
[0116] The interconnect 50 interconnects the door control- 
lers 52 and is typically a mix of wired and wireless com- 
ponents. However, it should be understood that the inter- 
connect 50 may instead comprise only wired components or 
only wireless components, that the wired components may 
include optical fibers, electrical wires, or any other type of 
physical structure over which the door controllers 52 can 
communicate, and that the wireless components may include 
RF links, optical links, magnetic links, sonic links, or any 
other type of wireless link over which the door controllers 52 
can communicate. 

[0117] The smart cards 42 carry the finite state automata 
pertinent to the corresponding user. Upon an access request, 
the access decision is made locally by the smart card 42 by 
virtue of the interaction between the smart card 42, which 
carries the finite state automata, and the door controller 52, 
which supplies the context information (such as the current 
occupancy level of the room). The smart card 42 uses both 
the finite state automata and the system context in order to 
make a decision regarding the request for access by user 
through the door 46. 

[0118] The interconnect 50 is used to transfer system-level 
information to the door-controllers 52, as opposed to per- 
user access request information, and to program the door- 
controllers 52. 

[0119] The users are expected to re-program, re-flash, or 
otherwise alter the finite state automata stored on their smart 
cards 42 on an agreed upon granularity so that they can 
reflect any change in policies. 

[0120] Thus, instead of a central controller storing the 
entire Access Control List as is done in traditional access 
control systems, the pertinent portions thereof (i.e., of the 
policies) are stored on the user's smart card 42 in connection 
with the access control system 40. The door controller 52 
and the smart cards 42 communicate with one another in 
order to correct execute the finite state automata and hence 
control access to the room 48. 

[0121] As indicated above, the finite state automata stored 
on the smart card 42 may be personal to the user possessing 
the smart card 42. For example, the smart card 42 of user A 
may contain a policy specifying that user A is permitted 
access to a room only if user B is already in the room. 
However, the smart card 42 of user C may contain no such 
finite state automata. 

[0122] As an example, one of the rules might specify that 
entry into a particular one of the rooms 48 is allowed only 
if occupancy in this particular room is less then twenty (e.g., 
the capacity limit of this room). The context is the current 
occupancy of this room. The door controller 52, which is 
charged with imposing the system context, maintains a count 



of the occupants of the room. When a user with a smart card 
42 that has a finite state automaton corresponding to the 
above policy requests access to the room, the policy is 
evaluated by the smart card 42 after applying the system 
context which it receives from the door controller 52 and 
makes the access decision to grant or deny access. 
[0123] The interconnect 50 may be arranged to include a 
system administrator 54 some of whose functions are dis- 
cussed above. 

[0124] A representative one of the smart cards 42 is shown 
in FIG. 7. The smart card 42 includes a memory 60, a 
processor 62, a transceiver 64, and a power source 66. The 
memory 60, for example, may be a flash memory and stores 
the finite state automaton that enforces the policies targeted 
to the user carrying the smart card 42. 
[0125] The smart card 42 may be arranged to respond to 
a generic read signal that is transmitted continuously, peri- 
odically, or otherwise by the reader 44, that is short range, 
and that requests any of the smart cards 42 in its vicinity to 
transmit its ID, and/or a request for system context, and/or 
other signal to the reader 44. In response to the read signal, 
the smart card 42 transmits the appropriate signal to the 
reader 44. 

[0126] Accordingly, when the user presents the user's 
smart card 42 to the reader 44, the transceiver 64 receives 
from the reader 44 at least the system context provided by 
the door controller 52. Based on this system context and the 
finite state automata stored in the memory 60, the processor 
62 makes the access decision to grant or deny the user access 
to the room 48 associated with the reader 44 to which the 
user's smart card 42 is presented. The processor 62 causes 
the grant decision to be transmitted by the transceiver 64 to 
the reader 44. If desired, the processor 62 may be arranged 
to also cause the deny decision to be transmitted by the 
transceiver 64 to the reader 44. 

[0127] The memory 60 may also be arranged to store a 
personal ID of the user to which the access card is assigned. 
When the user presents the smart card 42 to the reader 44, 
the processor 62 may be arranged to cause the user's 
personal ID to be transmitted by the transceiver 64 to the 
reader 44. In this manner, particular users may be barred 
from specified ones of the rooms 48, access by specific users 
to specific rooms, etc. may be tracked. Also, the door 
controllers 52 can be arranged to provide back certain 
system contexts that are targeted to particular users. 
[0128] The memory 60 can also store other information. 
[0129] The processor 62, for example, may be a micro- 
computer, a programmable gate array, an application spe- 
cific integrated circuit (ASIC), a dedicated circuit, or other 
processing entity capable of performing the functions 
described herein. 

[0130] The power source 66 may be a battery, or the power 
source 66 may be arranged to derive its power from trans- 
missions of the readers 44, or the power source 66 may be 
any other device suitable for providing power to the memory 
60, the processor 62, and the transceiver 64. 
[0131] The transceiver 64 transmits and receives over a 
link 68. The link 68 may be a wired link or a wireless link. 
[0132] A representative one of the readers 44 is shown in 
FIG. 8. The reader 44 includes a transceiver 70, a processor 
72, a transceiver 74, and a power source 76. Although not 
shown, the reader 44 may also include a memory. 
[0133] When the user presents the user's smart card 42 to 
the reader 44, the processor 72 causes the transceiver 74 to 
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send a signal to the door controller 52 that the smart card 42 
is being presented to the reader 44. This signal prompts the 
door controller 52 to transmit appropriate system context to 
the reader 44. The system context supplied by the door 
controller 52 is received by the transceiver 74 of the reader 
44. The processor 72 causes the system context received 
from the door controller 52 to be transmitted by the trans- 
ceiver 70 to the smart card 42. The access decision made and 
transmitted by the smart card 42 is received by the trans- 
ceiver 70. The processor 72 causes this decision to be 
transmitted by the transceiver 74 to the door controller 52. 
[0134] The processor 72, for example, may be a micro- 
computer, a programmable gate array, an application spe- 
cific integrated circuit (ASIC), a dedicated circuit, or other 
processing entity capable of performing the functions 
described herein. 

[0135] The power source 76 may be a battery, or the power 
source 76 may be a plug connectable to a wall or other 
outlet, or the power source 76 may be any other device 
suitable for providing power to the transceiver 70, the 
processor 72, and the transceiver 74. 
[0136] The transceiver 70 transmits and receives over a 
link 78. The link 78 may be a wired link or a wireless link. 
The transceiver 74 transmits and receives over a link 80. The 
link 80 may be a wired link or a wireless link. 
[0137] A representative one of the door controllers 52 is 
shown in FIG. 9. The door controller 52 includes a trans- 
ceiver 90, a processor 92, a transceiver 94, a memory 96, one 
or more context detectors 98, and a power source 100. 
[0138] When the user presents the user's smart card 42 to 
the reader 44 and the reader 44 sends a signal requesting the 
appropriate system context, the transceiver 90 receives this 
request signal causing the processor 92 to control the 
transceiver 90 so as to transmit this system context to the 
reader 44. The system context may be stored in the memory 
96. For example, the system context stored in the memory 96 
may be user specific and may be stored in the memory 96 by 
user ID. Thus, when a user's smart card 42 transmits its user 
ID to the door controller 52 via the reader 44, the door 
controller 52 transmits back system context specific to the 
user ID that it has received. 

[0139] At least a portion of the system context can be 
provided by the context detector 98. The context detector 98 
may simply be a counter that counts the number of users 
permitted in the room 48 guarded by the door controller 52. 
However, the context detector 98 may be arranged to detects 
additional or other system contexts to be stored in the 
memory 96 and to be transmitted to the reader 44 and then 
to the smart card 42. 

[0140] The transceiver 94 is arranged to exchange com- 
munications with the interconnect 50. 
[0141] The processor 92, for example, may be a micro- 
computer, a programmable gate array, an application spe- 
cific integrated circuit (ASIC), a dedicated circuit, or other 
processing entity capable of performing the functions 
described herein. 

[0142] The power source 100 may be a battery, or the 
power source 100 may be a plug connectable to a wall or 
other outlet, or the power source 100 may be any other 
device suitable for providing power to the transceiver 90, the 
processor 92, the transceiver 94, the memory 96, and the 
context detector 98. 

[0143] The transceiver 90 transmits and receives over a 
link 102. The link 102 may be a wired link or a wireless link. 



The transceiver 94 transmits and receives over a link 104. 
The link 104 may be a wired link or a wireless link. 
[0144] Accordingly, context-sensitive policy enforcement 
is de-centralized. Thus, there is no need for controllers to 
centrally maintain information about per-user permissions 
and system context. Instead, access control decisions are 
made locally, with the door-controllers dynamically main- 
taining pertinent environmental system context. This de- 
centralization alleviates the problem of scalability as the 
number of users and the complexity of the policies grow and 
the need for wireless interconnects increases. 
[0145] Moreover, the access control system 40 is easy to 
configure and re-configure. At a high level, the readers 44 
and/or the door controllers 52 are equipped with the knowl- 
edge of what they are protecting, but not how they are 
protecting (which is provided by the smart card 42 of each 
user who wants to access to the rooms 48.) The readers 44 
and/or door controllers 52 are stateless in this regard, 
making reconfiguration of the facility easier. 
[0146] Further, effective decentralization and localization 
of policy decision making also enables meaningful enforce- 
ment of at least some access control policies in the event of 
a disconnected or partially connected reader 44 and/or door 
controller 52. For example, policies depending only on a 
user's past behavior (and not on other system context) can 
be enforced even if a door controller 52 is disconnected from 
the system through the interconnect 50. 
[0147] Sophisticated approaches exist for secure authori- 
zation (albeit not for context-sensitive policies). For 
example, using symmetric key encryption, where all the 
access agents and the administrator 54 share a secret key k, 
with which they will be configured at the time of installation 
(or on a subsequent facility -wide reset operation, if the key 
is compromised), the per-user policy engine and states can 
be encrypted with k on the user-carried devices, and the 
readers 44 and/or the door controllers 52 can decrypt them 
using k and further write back encrypted states using k on 
the user-carried devices. This symmetric key encryption 
ensures security as long as k is not compromised. 
[0148] Certain modifications have been discussed above. 
Other modifications will occur to those practicing in related 
arts. For example, as described above, the smart cards 42 
make the access decision as to whether a user is to be 
permitted or denied access to a room. The smart card 42 
makes this decision based on the finite state automata that it 
stores and the system context provided by the door control- 
ler 52. Instead, the door controller 52 could make the access 
decision as to whether a user is to be permitted or denied 
access to a room based on the policies 52 provided by the 
smart card 42 and the system context stored in the memory 
96 of the door controller 52. 

[0149] Also, the reader 44 and the door controller 52 are 
shown as separate devices. Instead, their functions may be 
combined into a single device. 

[0150] Moreover, the functions of the door controller 52 
may be moved to the readers 44 reducing the door controller 
52 to a simple lock. 

[0151] In addition, the connections shown in FIG. 6 may 
be wired connections, or wireless connections, or a mixture 
of wired connections and wireless connections. 
[0152] Furthermore, the door controllers 52 may be 
arranged to log access decisions in a log file so that the 
decisions logged in the log file can be subsequently collated 
by a separate process for book-keeping. 
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[0153] Moreover, as discussed above, the interconnect 50 
of FIG. 6 may include the administrator 54. The system 
administrator 54 may to supply special system contexts that 
are in addition to any system contexts detected by the 
context detectors 98. Such special system contexts, for 
example, may be used to take care of emergency situations 
including but not limited to revoking the access rights of a 
rogue user. 

[0154] Accordingly, the detailed description is to be con- 
strued as illustrative only and is for the purpose of teaching 
those skilled in the art the best mode of carrying out the 
method and/or apparatus described. The details may be 
varied substantially without departing from the spirit of the 
invention claimed below, and the exclusive use of all modi- 
fications which are within the scope of the appended claims 
is reserved. 

What is claimed is: 

1. A method implemented on a computer for producing an 
automaton capable of providing an access control decision 
upon receiving an access control request, the method com- 
prising: 

accepting context based access control policies specified 
in a formal descriptive language; 

processing the context based access control policies speci- 
fied in the formal descriptive language; and, 

converting the context based access control policies to the 
automaton. 

2. The method of claim 1 wherein the processing of the 
context based access control policies specified in a formal 
descriptive language comprises processing the context based 
access control policies in the form of events. 

3. The method of claim 2 wherein the processing of the 
context based access control policies in the form of events 
comprises processing the context based access control poli- 
cies in the form of events specified in terms of a user s, a 
restricted area o of a secured facility, and an access point d 
permitting entrance to or exit from the restricted area o. 

4. The method of claim 2 wherein the processing of the 
context based access control policies in the form of events 
comprises processing the context based access control poli- 
cies in the form of events specified in terms of a user s, a type 
of user s, a restricted area o of a secured facility, a type of 
restricted area o, and an access point d permitting entrance 
to or exit from the restricted area o. 

5. The method of claim 1 wherein the processing of the 
context based access control policies specified in the formal 
descriptive language comprises processing access control 
actions and context specified as events, and wherein the 
events are included in an alphabet set of the language. 

6. The method of claim 1 wherein the automaton com- 
prises a finite state machine. 

7. The method of claim 1 wherein the converting of the 
context based access control policies to the automaton 
comprises: 

converting the context based access control policies to 

formulas including events and variables; and, 
converting the formulas to the automaton. 

8. The method of claim 7 wherein the automaton com- 
prises a finite state machine. 

9. The method of claim 7 wherein the converting of the 
context based access control policies to formulas comprises 
converting the context based access control policies to 
monadic second order formulas. 



10. The method of claim 7 wherein the converting of the 
context based access control policies to formulas including 
events and variables comprises converting the context based 
access control policies to formulas including events speci- 
fied in terms of a user s, a restricted area o of a secured 
facility, and an access point d permitting entrance to or exit 
from the restricted area o. 

11. The method of claim 7 wherein the converting of the 
context based access control policies to formulas including 
events and variables comprises converting the context based 
access control policies to formulas including events speci- 
fied in terms of a user s, a type of user s, a restricted area o 
of a secured facility, a type of restricted area o, and an access 
point d permitting entrance to or exit from the restricted area 
o. 

12. The method of claim 7 wherein the converting of the 
context based access control policies to formulas including 
events and variables comprises converting the context based 
access control policies to formulas including events, vari- 
ables, and Boolean operators. 

13. The method of claim 1 further comprising: 
formally verifying if a set of behaviors of a facility subject 

to the access control policies represented as formal 
descriptive language satisfies one or more of the access 
control policies; and, 
checking if one or more of the access control policies can 
be together enforced on a particular facility subject to 
the access control policies. 

14. The method of claim 1 further comprising storing the 
automaton in memory. 

15. The method of claim 14 wherein the storing of the 
automaton in memory comprises storing the automaton on 
an identification device carried by a user. 

16. The method of claim 14 wherein the storing of the 
automaton in memory comprises storing the automaton on a 
door controller. 

17. The method of claim 14 wherein the storing of the 
automaton in memory comprises storing the automaton in a 
plurality of memories. 

18. A method implemented on a computer for producing 
finite state automata capable of providing an access control 
decision upon receiving an access control request, the 
method comprising: 

reading context based access control policies specified in 
a formal descriptive language; 

converting the context based access control policies speci- 
fied in the formal descriptive language to Monadic 
Second Order formulae; and, 

converting the Monadic Second Order formulae to the 
finite state automata. 

19. The method of claim 18 wherein the converting of the 
context based access control policies comprises converting 
the context based access control policies specified in the 
formal descriptive language to Monadic Second Order event 
based formulae. 

20. The method of claim 19 wherein the event based 
formulae contain terms relating to a user s, a restricted area 
o of a secured facility, and an access point d permitting 
entrance to or exit from the restricted area o. 

21. The method of claim 19 wherein the event based 
formulae contain terms relating to a user s, a type of user s, 
a restricted area o of a secured facility, a type of restricted 
area o, and an access point d permitting entrance to or exit 
from the restricted area o. 
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22. The method of claim 18 wherein the converting of the 
context based access control policies comprises converting 
the context based access control policies specified in the 
formal descriptive language to Monadic Second Order event 
and variable based formulae. 

23. The method of claim 18 wherein the converting of the 
context based access control policies comprises converting 
the context based access control policies specified in the 
formal descriptive language to Monadic Second Order 
event, variable, and Boolean operator based formulae. 



24. The method of claim 18 further comprising storing the 
finite state automata in memory. 

25. The method of claim 24 wherein the storing of the 
finite state automata in memory comprises storing the finite 
state automata on an identification device carried by a user. 

26. The method of claim 24 wherein the storing of the 
finite state automata in memory comprises storing the finite 
state automata on a door controller. 



